跨領域轉職PM既不懂資訊專業，溝通手段也尚未純熟，容易不小心講錯話出包。
可能不小心對客戶太過誠實把老底全部揭開，或者記錯用詞產生不應發生的誤會。
說話或留下文字紀錄前，先釐清目標範疇，99%確認自己說的話不會挖坑給自家人跳，再回答也不遲，切勿別人急著要答案就跟著焦慮而混亂。

說話跟文字都保留餘地

一沒有資訊專業，二沒有說話尺度標準，不知道或不確定狀況時，話不要講滿，適度運用有解釋空間的文字。
以其他專案經驗來說這【可能】是⋯⋯
這個需求我們理解了但還需【評估】可行性⋯⋯
技術面可達到但時間與成本待【討論】才能規劃⋯⋯
我聽過工程師因為PM亂答應而生氣喊道：「都說可以，那PM他自己來開發啊！」
PM可能沒辦法從技術方面思考太周全，所以自己辦不到、還需考慮工程師有沒有充裕時間或能力，沒有十足經驗值可以拍胸保證時就多給自己留條後路吧。
PM無法立刻回應客戶的問題，只要積極讓客戶知道PM有在處理和追蹤問題，客戶都有耐心可以等待，而且不會認為PM總是承諾了但食言。
若是總逞快答應但每每逾期甚至辦不到，客戶覺得無法信任PM之後就很難合作了。

無法自己判斷則須「授權」再對外說話

先緩和客戶爭取到討論時間，內部有結論後的轉述又是一大關卡。
分析師、工程師等專家往往能提供專業的「技術建議」，需要和客戶說多少、用什麼策略來對話則是PM的功課。
剛轉職的菜鳥PM大概都還無法拿捏對外說話的輕重，也代表在這之上應該會有另一名主責PM或主管在扶持引導菜鳥PM。
既然如此請好好利用「導師」的資源，即使主責PM或主管沒有明文規定對外揭露的資訊須經過審核，也盡量多此一舉請示導師：「這樣說/寫給客戶OK嗎？」
導師的閱歷豐富，可以協助判斷什麼格式的文件、什麼關鍵字是禁忌，勝者還能潤飾精短語句但更直觀有力。
最重要的是，請示並經過同意的話語或文字出去之後，如果發生什麼問題，至少這是「經過授權」的行為，算是小小保護自己的手段，有肩膀的導師會一起承擔責任幫忙，不想負責的主管也脫不了干係無法單獨咎責於菜鳥PM。

揭露資訊需考量風險

等較有信心可以獨立和客戶對話，每次說話前還是務必三思，因為說出去的話可能覆水難收。

一、容易影響「成本」的內容需再三確認標準規格

要準備答應客戶什麼東西嗎？
想清楚再說，不小心會一語成讖變成「多說多做」。
「服務建議書」和「承諾書」等可能納入契約書的文字也須注意，有時複製貼上其他專案的公版內容，可能不小心免費多送給客戶本不是契約範疇的服務。
以客服電話舉例，如果筆誤寫成「客服專線」那成本跟「兼職的客服電話」差很多，變成需要專門一位客服人員搭配獨立門號接電話。
軟硬體的規格也是容易誤植內容的領域，最好請不同人多看幾眼。

二、影響內外專案「時程」的風險則多爭取緩衝時間

需求變更、提早履約等容易壓縮執行時間，未來可能隨時殺出程咬金瓜分任務時間。
不確定的時程只回報客戶「預計開發時間」是不夠的，分析時可能來來回回問答、測試或許因為環境問題被迫中斷重來、工程師確診需休息等等，風險有百百種可能危害到專案進程。
以實際所需開發時間多估算2、3倍，才是較保險的「執行時間」。
等有經驗之後，PM可以借鑑慘痛經驗和客戶稍微分享心得。
例如：
和某銀行「介接」光開通防火牆的申請可能需要一個月時間，測試機好不容易可以轉換到正式機，正式機還需要另外開通不知名權限又耗費掉幾天，實際開發只需不到一個月的程式，搞了3個月才正式上線。
所以如果要開發類似需要介接的功能，絕對絕對要多預留時間，跟長官回報3個月結果提早做完就皆大歡喜；反之太過自信但不斷逾期才完成，顯得非常落漆。

三、關乎團隊「專業聲譽」的問題小心處理

名聲與信心一旦搞砸是很難挽回的，專案有異常狀況時記得適當適時揭露資訊。
「適當適時揭露」不等於「欺騙」，撒謊只會謊言越滾越大，東窗事發只會苦了自己和團隊的大家，也會造成客戶不信任團隊。
如果工程師回報說維護時發現不認識的執行檔，這件事需要報告給客戶知道嗎？
一定要回報，但我的話不會立刻報告說發現了這個檔案。
當務之急先請團隊內所有工程師或高層主管幫忙釐清「執行檔可能產生原因」、「有無駭客入侵紀錄，沒有的話需舉證系統仍然安全」等問題。
儘速釐清完再「回報完整資訊」給客戶。
如果分階段先回報說發現「陌生執行檔」，客戶不跳起來嚇死才怪，大多會聯想到資安事件；結果盤查後發現是之前的工程師沒歸檔正確、交接換新工程師維護才烏龍一場，客戶應該會想砍了製造恐慌的PM。

上述不是在鼓吹PM不老實，表達一向是難學深奧的藝術，「思索周全的說話保守」不僅是保護專案的技能，也能避免散播不必要的恐慌。